home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_1199 / 936 < prev    next >
Internet Message Format  |  1994-08-27  |  3KB
  1. From: "Kevin O'Donovan" <abaddon@nasoftwr.demon.co.uk>
  2. Subject: Re: Dialogs!
  3. Date: Thu, 21 Jul 1994 10:49:42 +0100 (BST)
  4. In-Reply-To: <Pine.3.87.9407210138.A781-0100000@grad> from "Timothy Miller" at Jul 21, 94 01:46:38 am
  5. X-Tremely: Sexy
  6. Precedence: bulk
  7.  
  8. > We're saying to stop using dialogs.
  9. >
  10. I don't think that's what's being said. Stop using form_do() perhaps, but
  11. not stop using dialogs. Just use them differently.
  12.  
  13. > Hey, this is the way GEM is.  If we're going to require dialogs to be in 
  14. > windows, then it should made part of the operating system.  
  15. >
  16. Well, I'm an X developer when I'm not working on the atari, so I can't speak
  17. for Macs or PCs, but putting your forms in windows is not something the OS
  18. does for you under any of the X toolkits, its up to the programmer. For that
  19. matter, amodal form handling is not part of X per se, its provided by the
  20. various toolkits. If you were to program at the basic X level then it would
  21. be quite possible to have multiple event loops in different parts of your
  22. code, and produce a modal application. And anyway, see below...
  23.  
  24. > functionality of the OS.  MultiTOS and Geneva should put dialogs for apps 
  25. > automatically into windows and handle them accordingly.
  26. >
  27. And how do you see this working? The applications need to be changed as well,
  28. or putting the forms in windows is going to do nothing more than giving them
  29. a border. If you've got a form that can stay up whilst the rest of the program
  30. is running then you're program has got to be able to accept events from it
  31. at any time. There's no way the OS could do this for you.
  32.  
  33. > Every new program that supports that section of the GEM-List standards 
  34. > should put dialogs in windows.  Fine.  Every program that wants to 
  35. > properly support multuitasking, definately.
  36. >
  37. In the end people will use the programs they like irrespective of wether or
  38. not they match our standards.
  39.  
  40. > But then you still have the problem of every program containing extra 
  41. > code for handling dialogs in windows, and each program having a different 
  42. > handler from a different library developer.  There will be a lack of 
  43. > consistency and a lot of wasted space.
  44. >
  45. Which is why I'm thinking in terms of a shared library option for my toolkit.
  46. At least that way all apps that use my toolkit will only require one instance
  47. of the library. As for consistency, isn't that what this list is here for?
  48.  
  49. > 5k DA that's intended to make some setting and then quit certainly 
  50. > shouldn't be required to puts its dialog in a window.  You won't have the 
  51. > dialog open long enough!
  52. Well no, it shouldn't be required, but its still just as desirable that it
  53. should. What if you need to check something elsewhere before making that
  54. setting? 
  55.  
  56. > And then to make standards on something as open-ended and unexplored as 
  57. > amodal dialogs is not reasonable.
  58. I sort of agree on this, however I don't think amodal dialogs are unexplored.
  59. They've existed on other platforms for a long time, and standards have been
  60. set on those platforms - lets steal some ideas
  61.  
  62.  
  63. >   Let's let a few developers 
  64. > take a crack at it, using their own ideas and see what people really use 
  65. > and want.
  66. Wether we like it or not, this is what is going to happen.
  67.  
  68. > Can someone tell me how to set up menu_popup's?
  69.  
  70. Wouldn't you be better asking this in comp.sys.atari.st.tech?
  71.  
  72. Kev
  73.  
  74. -- 
  75. Kevin O'Donovan
  76. abaddon@nasoftwr.demon.co.uk
  77. kebab@cix.compulink.co.uk
  78.  
  79. Earth shutting down in five minutes--please save all files and log out
  80.  
  81.